-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-32049][SQL][TESTS] Upgrade Oracle JDBC Driver 8 #28893
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
I've just re-executed |
|
cc @gatorsmile @dongjoon-hyun @maropu @MaxGekk to pull everybody in who helps in #28863 |
|
Test build #124364 has finished for PR 28893 at commit
|
|
retest this please |
|
Filed SPARK-32054 |
|
Test build #124367 has finished for PR 28893 at commit
|
ojdbc8
ojdbc8
dongjoon-hyun
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for making a PR, @gaborgsomogyi .
Unfortunately, this doesn't pass the IT test because this PR doesn't include the following as you described.
The timeout and interval parameter to be increased to a high value for oracle test in
DockerJDBCIntegrationSuite.scala (Locally tested with 20 min timeout and 1 sec interval
Technically, this dies like the following.
$ docker logs 1380b6c16cff -f
ORACLE PASSWORD FOR SYS AND SYSTEM: oracle
Specify a password to be used for database accounts. Oracle recommends that the password entered should be at least 8 characters in length, contain at least 1 uppercase character, 1 lower case character and 1 digit [0-9]. Note that the same password will be used for SYS, SYSTEM and PDBADMIN accounts:
Confirm the password:
Configuring Oracle Listener.
Listener configuration succeeded.
Configuring Oracle Database XE.
Enter SYS user password:
******
Enter SYSTEM user password:
*****
Enter PDBADMIN User Password:
******
Prepare for db operation
7% complete
Copying database files
29% complete
Creating and starting Oracle instance
30% complete
31% complete
34% complete
---- die here ----
In this case, the documentation is insufficient because this cannot be used during RC vote or automated test. During RC vote or automated test, we are testing on the untouched source code.
| * 6. Run spark test - ./build/sbt "test-only org.apache.spark.sql.jdbc.OracleIntegrationSuite" | ||
| * 4. The timeout and interval parameter to be increased to a high value for oracle test in | ||
| * DockerJDBCIntegrationSuite.scala (Locally tested with 20 min timeout and 1 sec interval | ||
| * then executed successfully). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
20 min looks like a magic number. After repeating some, 5 minutes seems sufficient in some cases.
Or, we can introduction a new val or def connectionTimeout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's magically high enough not to cause issues. I personally would not add further complexity but just increase the timeout.
|
I made a PR to you. Could you review and consider that? |
| <artifactId>ojdbc8</artifactId> | ||
| <version>19.6.0.0</version> | ||
| <scope>test</scope> | ||
| </dependency> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to update this root pom in this PR? It seems this change is related to the ohter PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is questionable but I think rolling this back and adding it in the next commit ends-up more work nominally. Apart from that purely personal taste but I like the dependency management way of dep handling (even if only one reference exists).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, but, if this PR is reverted for some reason after the two PRs have been merged, will the other PR break? I think each PR should be as independent as possible for backports/reverts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly not considered independency but I agree with the direction. I would like to understand your point but not yet able. Here we're considering on which side the dep management will be. We can consider dep management change as an additional complexity at the top of the actual code base. If we move that from this PR into the other one will make this more independent but on the other side will make the other one less independent. I see this as a tradeoff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but on the other side will make the other one less independent.
You meant #28863 can avoid the dependency for this oracle driver in the root pom? I thought you added the dependency in #28863 for adding some secure connector's tests in the core package:
https://github.com/apache/spark/pull/28863/files#diff-0b713a218f4e99665e339404f7b6c6c3R153-R157
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this one, I believe it's okay because now we have all SQL drivers in one place. In this root pom, we have MySQL/Maria/PostgreSQL/DB2/MsSqlServer already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you think about that, @maropu ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see. Looks okay now. Thanks, @dongjoon-hyun and @gaborgsomogyi
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you guys for the clarification.
|
Thanks for the work, @gaborfeher ! |
This justifies the need to fix the hack properly. I've just double checked your suggestion and seems like I have bad luck because the test consumed ~5 minutes and 3 seconds. Increasing it to 7 minutes to have some room and avoid flaky behaviour. |
Other Gabor :) |
| jdbcUrl = db.getJdbcUrl(dockerIp, externalPort) | ||
| var conn: Connection = null | ||
| eventually(timeout(2.minutes), interval(1.second)) { | ||
| eventually(timeout(7.minutes), interval(1.second)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gaborgsomogyi . 7 minutes is okay for Oracle suite. But, it seems that you misunderstand my PR. You can use more higher values, but you should not increase the timeout of the other test suites. Please see my PR. I keep 2.minutes for all the other test suite and only allow longer timeout for OracleIntegrationSuite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the way...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, just read back the situation. Here I've read 5 minutes what I've thought is a bit small so changed the code manually. Just seen your effort which contains 10 minutes :) Sorry...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Ya. During review, I didn't update my original comment. My bad. I should be more clear on the PR.
|
Test build #124412 has finished for PR 28893 at commit
|
|
retest this please |
|
Test build #124413 has finished for PR 28893 at commit
|
|
Gosh, again this issue: Retrying after lunch... |
dongjoon-hyun
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, LGTM. This is an integration test and I verified manually.
Thank you, @gaborgsomogyi and @maropu .
Merged to master.
|
Test build #124405 has finished for PR 28893 at commit
|
|
Just arrived back and seen the status. |
What changes were proposed in this pull request?
OracleIntegrationSuiteis not using the latest oracle JDBC driver. In this PR I've upgraded the driver to the latest which supports JDK8, JDK9, and JDK11.Why are the changes needed?
Old JDBC driver.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Existing unit tests.
Existing integration tests (especially
OracleIntegrationSuite)